Stream: Internet Research Task Force (IRTF) 


RFC: 9269 

Category: Informational 

Published: August 2022 

ISSN: 2070-1721 

Authors: P. Suthar M. Stolic A. Jangam, Ed. D. Trossen 


Google Inc. Cisco Systems Inc. Cisco Systems Inc. | Huawei Technologies 


R. Ravindran 
F5 Networks 


RFC 9269 
Experimental Scenarios of Information-Centric 
Networking (ICN) Integration in 4G Mobile Networks 


Abstract 


A 4G mobile network uses IP-based transport for the control plane to establish the data session at 
the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used 
for the delivery of multimedia content to a mobile terminal, where each user is receiving a 
separate stream from the server. From a bandwidth and routing perspective, this approach is 
inefficient. Evolved multimedia broadcast and multicast service (EMBMS) provides capabilities 
for delivering contents to multiple users simultaneously, but its deployment is very limited or at 
an experimental stage due to numerous challenges. The focus of this document is to list the 
options for using Information-Centric Networking (ICN) in 4G mobile networks and elaborate the 
experimental setups for its further evaluation. The experimental setups discussed provide 
guidance for using ICN either natively or with an existing mobility protocol stack. With further 
investigations based on the listed experiments, ICN with its inherent capabilities such as 
network-layer multicast, anchorless mobility, security, and optimized data delivery using local 
caching at the edge may provide a viable alternative to IP transport in 4G mobile networks. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the 
results of Internet-related research and development activities. These results might not be 
suitable for deployment. This RFC represents the consensus of the Information-Centric 
Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for 
publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of 
RFC 7841. 
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1. Introduction 


4G mobile technology is built as an all-IP network using routing protocols (OSPF, IS-IS, BGP, etc.) 
to establish network routes. The stickiness of an IP address to a device is the key to getting 
connected to a mobile network. The same IP address is maintained through the session until the 
device gets detached or moves to another network. 


Key protocols used in 4G networks are the General Packet Radio Service Tunneling Protocol 
(GTP), DIAMETER, and other protocols that are built on top of IP. One of the biggest challenges 
with IP-based routing in 4G is that it is not optimized for data transport. As an alternative to IP 
routing, this document presents and lists the possible options for integration of Information- 
Centric Networking (ICN) in 3GPP 4G mobile networks, offering an opportunity to leverage 
inherent ICN capabilities such as in-network caching, multicast, anchorless mobility 
management, and authentication. This document also discusses how those options affect mobile 
providers and end users. 


The goal of the proposed experiments is to present possibilities to create simulated environments 
for evaluation of the benefits of ICN protocol deployment in a 4G mobile network in different 
scenarios that have been analyzed in this document. The consensus of the Information-Centric 
Networking Research Group (ICNRG) is to publish this document in order to facilitate 
experiments to show deployment options and qualitative and quantitative benefits of ICN 
protocol deployment in 4G mobile networks. 


2. 3GPP Terminology and Concepts 
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Access Point Name: The Access Point Name (APN) is a Fully Qualified Domain Name (FQDN) and 
resolves to a set of gateways in an operator's network. An APN identifies the packet data 
network (PDN) with which a mobile data user wants to communicate. In addition to 
identifying a PDN, an APN may also be used to define the type of service, QoS, and other 
logical entities inside a Gateway General Packet Radio Service Support Node (GGSN) ora 
Packet Data Network Gateway (PGW). 


Control Plane: The control plane carries signaling traffic and is responsible for routing between 
the eNodeB and the Mobile Management Entity (MME), the MME and the Home Subscriber 
Server (HSS), the MME and the Mobile Gateways (SGW/PGW), etc. Control plane signaling is 
required to authenticate and authorize the mobile terminal and establish a mobility session 
with Mobile Gateways (SGW/PGW). Control plane functions also include system configuration 
and management. 


Dual Address PDN/PDP Type: The dual address Packet Data Network / Packet Data Protocol 
(PDN/PDP) Type (IPv4v6) is used in 3GPP context, in many cases as a synonym for dual stack, 
i.e., a connection type capable of serving IPv4 and IPv6 simultaneously. 


eNodeB: The eNodeB is a base station entity that supports the Long Term Evolution (LTE) air 
interface. 


Evolved Packet Core: The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system 
characterized by a higher-data-rate, lower-latency, packet-optimized system. The EPC 
comprises some subcomponents of the EPS core such as MME, Mobile Gateways (SGW/PGW), 
and HSS. 


Evolved Packet System: The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS 
system characterized by a higher-data-rate, lower-latency, packet-optimized system that 
supports multiple Radio Access Technologies (RATs). The EPS comprises the EPC together with 
Evolved Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal Terrestrial 
Radio Access Network (E-UTRAN). 


Evolved UTRAN: The Evolved UTRAN (E-UTRAN) is a communications network sometimes 
referred to as 4G, and it consists of an eNodeB (4G base stations). The E-UTRAN allows 
connectivity between the User Equipment and the core network. 


Gateway GPRS Support Node: The Gateway GPRS Support Node (GGSN) is a gateway function in 
the GPRS and 3G network that provides connectivity to the Internet or other PDNs. The host 
attaches to a GGSN identified by an APN that is assigned to it by an operator. The GGSN also 
serves as the topological anchor for addresses/prefixes assigned to the User Equipment. 


General Packet Radio Service: The General Packet Radio Service (GPRS) is a packet-oriented 
mobile data service available to users of the 2G and 3G cellular communication systems (the 
GSM) specified by 3GPP. 


GPRS Tunneling Protocol: The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274] [TS29.281] 
is a tunneling protocol defined by 3GPP. It is a network-based mobility protocol that works 
similarly to Proxy Mobile IPv6 (PMIPv6). However, GTP also provides functionality beyond 
mobility, such as in-band signaling related to QoS and charging, among others. 
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Home Subscriber Server: The Home Subscriber Server (HSS) [TS29.336] is a database for a 
given subscriber and was introduced in 3GPP Release 5. It is the entity containing 
subscription-related information to support the network entities that handle calls/sessions. 


Mobile Terminal/User Equipment: The terms User Equipment (UE), Mobile Station (MS), Mobile 
Node (MN), and mobile refer to the devices that are hosts with the ability to obtain Internet 
connectivity via a 3GPP network. An MS comprises the Terminal Equipment (TE) and an MT. 
The terms MT, MS, MN, and mobile are used interchangeably within this document. 


Mobility Management Entity: The Mobility Management Entity (MME) is a network element 
responsible for control plane functionalities, including authentication, authorization, bearer 
management, Layer 2 mobility, and so on. The MME is essentially the control plane part of the 
SGSN in the GPRS. The user-plane traffic bypasses the MME. 


Packet Data Network: The Packet Data Network (PDN) is a packet-based network that either 
belongs to the operator or is an external network such as the Internet or a corporate intranet. 
The user eventually accesses services in one or more PDNs. The operator's packet core 
networks are separated from packet data networks by either GGSNs or PGWs. 


Packet Data Network Gateway: The Packet Data Network Gateway (PGW) is a gateway function 
in the EPS, which provides connectivity to the Internet or other PDNs. The host attaches to a 
PGW identified by an APN that is assigned to it by an operator. The PGW also serves as the 
topological anchor for addresses/prefixes assigned to the User Equipment. 


Packet Data Protocol Context: A Packet Data Protocol (PDP) context is the equivalent of a virtual 
connection between the mobile terminal (MT) and a PDN using a specific gateway. 


Packet Data Protocol Type: A Packet Data Protocol Type (PDP Type) identifies the used/allowed 
protocols within the PDP context. Examples are IPv4, IPv6, and IPv4v6 (dual stack). 


Policy and Charging Control: The Policy and Charging Control (PCC) framework is used for QoS 
policy and charging control. It has two main functions: flow-based charging (including online 
credit control) and policy control (for example, gating control, QoS control, and QoS 
signaling). It is optional to 3GPP EPS but needed if dynamic policy and charging control by 
means of PCC rules based on user and services are desired. 


Public Land Mobile Network: The Public Land Mobile Network (PLMN) is a network operated 
by a single administration. A PLMN (and therefore also an operator) is identified by the 
Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) 
operator providing mobile services has its own PLMN. 


Serving Gateway: The Serving Gateway (SGW) is a gateway function in the EPS, which 
terminates the interface towards the E-UTRAN. The SGW is the Mobility Anchor point for 
Layer 2 mobility (inter-eNodeB handovers). For each mobile terminal connected with the EPS, 


there is only one SGW at any given point in time. The SGW is essentially the user-plane part of 
the GPRS's SGSN. 
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Serving GPRS Support Node: The Serving GPRS Support Node (SGSN) is a network element 
located between the Radio Access Network (RAN) and the gateway (GGSN). A per-MT point-to- 
point (P2P) tunnel between the GGSN and SGSN transports the packets between the mobile 
terminal and the gateway. 


User Plane: The user plane refers to data traffic and the required bearers for the data traffic. In 
practice, IP is the only data traffic protocol used in the user plane. 


3. 4G Mobile Network Architecture 


This section provides a high-level overview of typical 4G mobile network architecture and the 
key functions related to the possibility of its use with ICN technology. 


3.1. Network Overview 


4G mobile networks are designed to use IP transport for communication among different 
elements such as the eNodeB, MME, SGW, PGW, HSS, Policy and Charging Rule Function (PCRF), 
etc. [GRAYSON]. For backward compatibility with 3G, it has support for legacy circuit switch 
features such as voice and SMS through transitional CS fallback and flexible IP Multimedia 
Subsystems (IMS) deployment. For each mobile device attached to the radio (eNodeB), there is a 
separate overlay tunnel (GTP) between the eNodeB and Mobile Gateways (i.e., SGW/PGW). 


When any mobile terminal is powered up, it attaches to a mobile network based on its 
configuration and subscription. After a successful attachment procedure, the mobile terminal 
registers with the mobile core network using IPv4 and/or IPv6 addresses based on request and 
capabilities offered by Mobile Gateways. 


The GTP tunnel is used to carry user traffic between gateways and mobile terminals, therefore 
using the unicast delivery for any data transfer. It is also important to understand the overhead 
of GTP and IPsec protocols. All mobile backhaul traffic is encapsulated using a GTP tunnel, which 
has overhead of 8 bytes on top of IP and UDP [NGMN]. Additionally, if IPsec is used for security 
(which is often required if the Service Provider is using a shared backhaul), it adds overhead 
based on the IPsec tunneling model (tunnel or transport) as well as the encryption and 
authentication header algorithm used. If we consider an Advanced Encryption Standard (AES) 
encryption as an example, the overhead can be significant [OLTEANU], particularly for smaller 
payloads. 
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Figure 1: 4G Mobile Network Overview 


If we consider the combined impact of GTP, IPsec, and unicast traffic, the data delivery is not 
efficient because of overhead. The IETF has developed various header compression algorithms to 
reduce the overhead associated with IP packets. Some techniques are RObust Header 
Compression (ROHC) and Enhanced Compression RTP (ECRTP) so that the impact of overhead 
created by GTP, IPsec, etc., is reduced to some extent [BROWER]. For commercial mobile 
networks, 3GPP has adopted different mechanisms for header compression to achieve efficiency 
in data delivery [TS25.323]; those solutions can be adapted to other data protocols too such as 
ICN [RFC9139] [TLVCOMP]. 


3.2. Mobile Network Quality of Service 


During the mobile terminal attachment procedure, a default bearer is created for each mobile 
terminal and it is assigned to the default Access Point Name (APN), which provides the default 
transport. For any QoS-aware application, one or more new dedicated bearers are established 
between an eNodeB and a Mobile Gateway. A dedicated bearer can be requested by either a 
mobile terminal or a Mobile Gateway based on the direction of the first data flow. There are 
many bearers (logical paths) established between an eNodeB and a Mobile Gateway for each 
mobile terminal catering to a different data flow simultaneously. 
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While all traffic within a certain bearer receives the same treatment, QoS parameters supporting 
these requirements can be very granular in different bearers. These values vary for the control, 
management, and user traffic, and can be very different depending on application key 
parameters such as latency, jitter (important for voice and other real-time applications), packet 
loss, and queuing mechanism (strict priority, low latency, fair, and so on). 


Implementation of QoS for mobile networks is done at two stages: 1) content prioritization/ 
marking and transport marking and 2) congestion management. From the transport perspective, 
QoS is defined at Layer 2 as Class of Service (CoS) and at Layer 3 as Differentiated Services (DS). 
The mapping of the Differentiated Services Code Point (DSCP) to CoS takes place at Layer 2/3 
switching and routing elements. 3GPP has a specified QoS Class Identifier (QCD, which represents 
different types of content and equivalent mappings to the DSCP at the transport layer [TS23.401]. 
However, this requires manual configuration at different elements and is therefore prone to 
possible misconfigurations. 


In summary, QoS configuration in mobile networks for user-plane traffic requires 
synchronization of parameters among different platforms. Normally, QoS in IP is implemented 
using DiffServ, which uses hop-by-hop QoS configuration at each router. Any inconsistency in IP 
QoS configuration at routers in the forwarding path can result in a poor subscriber experience 
(e.g., a packet classified as high priority can go to a lower-priority queue). By deploying ICN, we 
intend to enhance the subscriber experience using policy-based configuration, which can be 
associated with the named contents [ICNQoS] at the ICN forwarder. Further investigation is 
underway to understand how QoS in ICN [QoS-ICN] can be implemented with reference to the 
ICN QoS guidelines [RFC9064] to meet the QoS requirements [RFC4594]. 


3.3. Data Transport Using IP 


The data delivered to mobile devices is sent in unicast semantic inside the GTP tunnel from an 
eNodeB to a PDN gateway (PGW) as described in 3GPP specifications [TS23.401]. While the 
technology exists to address the issue of possible multicast delivery, there are many difficulties 
related to multicast protocol implementations on the RAN side of the network. By using eMBMS 
[EMBMS], multicast routing can be enabled in mobile backhaul between an eNodeB and Mobile 
Gateways (SGW/PGW); however, for radio interface it requires broadcast, which implies that we 
need a dedicated radio channel. Implementation of eMBMS in RAN is still lagging behind due to 
complexities related to client mobility, handovers, and the fact that the potential gain to Service 
Providers may not justify the investment, which explains the prevalence of unicast delivery in 
mobile networks. Techniques to handle multicast (such as LTE-B or eMBMS) have been designed 
to handle pre-planned content delivery, such as live content, which contrasts user behavior 
today, largely based on a content (or video) on-demand model. 


To ease the burden on the bandwidth of the Service Gateway interface (SGi), caching is 
introduced in a similar manner as with many enterprises. In mobile networks, whenever 
possible, cached data is delivered. Caching servers are placed at a centralized location, typically 
in the Service Provider's Data Center, or in some cases lightly distributed in packet core locations 
with the PGW nodes close to the Internet and IP services access (SGi). This is a very inefficient 
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concept because traffic must traverse the entire backhaul path for the data to be delivered to the 
end user. Other issues, such as out-of-order delivery, contribute to this complexity and 
inefficiency, which needs to be addressed at the application level. 


3.4. Virtualized Mobile Networks 


The Mobile Gateways deployed in a major Service Provider network are based on either 
dedicated hardware or commercial off-the-shelf (COTS) x86 technology. With the adoption of 
Mobile Virtual Network Operators (MVNOs), public safety networks, and enterprise mobility 
networks, elastic mobile core architecture is needed. By deploying the mobile packet core ona 
COTS platform, using a Network Function Virtualization Infrastructure (NFVI) framework and 
end-to-end orchestration, new deployments can be simplified to provide optimized total cost of 
ownership (TCO). 


While virtualization is growing, and many mobile providers use a hybrid architecture that 
consists of dedicated and virtualized infrastructures, the control and data planes are still the 
same. There is also work underway to separate the control and user plane for the network to 
scale better. Virtualized mobile networks and network slicing with control and user-plane 
separation provide a mechanism to evolve the GTP-based architecture towards an OpenFlow 
with signaling based on Software-Defined Networking (SDN) for 4G and proposed 5G core. Some 
early architecture work for 5G mobile technologies provides a mechanism for control and user- 
plane separation and simplifies the mobility call flow by introducing OpenFlow-based signaling 
[ICN5G]. This has been considered by 3GPP [EPCCUPS] and is also described in [SDN5G]. 


4. Data Transport Using ICN 


For mobile devices, the edge connectivity is between a mobile terminal and a router or mobile 
edge computing (MEC) [MECSPEC] element. Edge computing has the capability of processing 
client requests and segregating control and user traffic at the edge of radio rather than sending 
all requests to the Mobile Gateway. 
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Figure 2: ICN Architecture 


Edge computing transforms a Radio Access Network into an intelligent service edge capable of 
delivering services directly from the edge of the network while providing the best possible 
performance to the client. Edge computing can be an ideal candidate for implementing ICN 
forwarders in addition to its usual function of managing mobile termination. In addition to edge 
computing, other transport elements, such as routers, can work as ICN forwarders. 


Data transport using ICN is different than IP-based transport as it introduces uniquely named- 
data as a core design principle. Communication in ICN takes place between the content provider 
(producer) and the end user (consumer), as described in Figure 2. 


Every node in a physical path between a client and a content provider is called the ICN 
forwarder or router. It can route the request intelligently and cache content so it can be 
delivered locally for subsequent requests from any other client. For mobile networks, transport 
between a client and a content provider consists of a radio network + mobile backhaul and IP 
core transport + Mobile Gateways + Internet + Content Delivery Network (CDN). 


To understand the suitability of ICN for mobile networks, we will discuss the ICN framework by 
describing its protocol architecture and different types of messages; this will be helpful when 
considering how to use ICN in mobile networks to deliver content more efficiently. ICN uses two 
types of packets called "interest packet" and "data packet" as described in Figure 3. 
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Figure 3: ICN Interest, Data Packet, and Forwarder 


In a 4G network, when a mobile device wants to receive certain content, it will send an Interest 
message to the closest eNodeB. Interest packets follow the TLV format [RFC8609] and contain 
mandatory fields such as the name of the content and content-matching restrictions (KeyIdRestr 
and ContentObjectHashRestr) expressed as a tuple [RFC8569]. The content-matching tuple 
uniquely identifies the matching data packet for the given Interest packet. Another attribute 
called "HopLimit" is used to detect looping Interest messages. 


An ICN router will receive an Interest packet and lookup if a request for such content has arrived 
earlier from another client. If so, it may be served from the local cache; otherwise, the request is 
forwarded to the next-hop ICN router. Each ICN router maintains three data structures: Pending 
Interest Table (PIT), Forwarding Information Base (FIB), and Content Store (CS). The Interest 
packet travels hop by hop towards the content provider. Once the Interest packet reaches the 
content provider, it will return a data packet containing information such as content name, 
signature, and the actual data. 


The data packet travels in reverse direction following the same path taken by the Interest packet, 
maintaining routing symmetry. Details about algorithms used in PIT, FIB, CS, and security trust 
models are described in various resources [CCN]; here, we have explained the concept and its 
applicability to the 4G network. 


5. Experimental Scenarios for ICN Deployment 


In 4G mobile networks, both user and control plane traffic have to be transported from the edge 
to the mobile packet core via IP transport. The evolution of the existing mobile packet core using 
Control and User Plane Separation (CUPS) [TS23.714] enables flexible networking and operations 
by distributed deployment and the independent scaling of control plane and user-plane 
functions while not affecting the functionality of existing nodes subject to this split. 
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In this section, we analyze the potential impact of ICN on control and user-plane traffic for 
centralized and disaggregated CUPS-based mobile network architecture. We list various 
experimental options and opportunities to study the feasibility of the deployment of ICN in 4G 
networks. The proposed experiments would help the network and original equipment 
manufacturer (OEM) designers to understand various issues, optimizations, and advantages of 
the deployment of ICN in 4G networks. 


5.1. General Considerations 


In the CUPS architecture, there is an opportunity to shorten the path for user-plane traffic by 
deploying offload nodes closer to the edge [OFFLOAD]. With this major architecture change, a 
User Plane Function (UPF) node is placed close to the edge so traffic no longer needs to traverse 
the entire backhaul path to reach the EPC. In many cases, where feasible, the UPF can be 
collocated with the eNodeB, which is also a business decision based on user demand. Placing a 
Publisher close to the offload site, or at the offload site, provides for a significant improvement in 
user experience, especially with latency-sensitive applications. This capability allows for the 
introduction of ICN and amplifies its advantages. 


5.2. Scenarios of ICN Integration 


The integration of ICN provides an opportunity to further optimize the existing data transport in 
4G mobile networks. The various opportunities from the coexistence of ICN and IP transport in 
the mobile network are somewhat analogous to the deployment scenarios when IPv6 was 
introduced to interoperate with IPv4 except, with ICN, the whole IP stack can be replaced. We 
have reviewed [RFC6459] and analyzed the impact of ICN on control plane signaling and user- 
plane data delivery. In general, ICN can be used natively by replacing IP transport (IPv4 and 
IPv6) or as an overlay protocol. Figure 4 describes a proposal to modify the existing transport 
protocol stack to support ICN in a 4G mobile network. 


+---------------- + +----------------- + 
| ICN App (new) | |IP App (existing) | 
$--------- +------ + +------- +--------- + 
N E S : 
| Transport Convergence Layer (new) | 
+------ +--------------------- +------- + 
+------ l ------ + +------ i ------- + 
|ICN function | | IP function | 
| (New l | (Existing) | 
+------ +------ + +------ +------- + 
| | 
Ce Co 
CNE Te 4 
( Cloud ) ( Cloud ) 
r Merit 


Figure 4: IP/ICN Convergence Scenarios 
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As shown in Figure 4, for applications (running either in the mobile terminal or in the content 
provider system) to use the ICN transport option, we propose a new transport convergence layer 
(TCL). The TCL helps determine the type of transport (such as ICN or IP) as well as the type of 
radio interface (LTE, Wi-Fi, or both) used to send and receive traffic based on preference (e.¢., 
content location, content type, content publisher, congestion, cost, or QoS). It helps configure and 
determine the type of connection (native IP or ICN) or the overlay mode (ICNoIP or IPoICN) 
between application and the protocol stack (IP or ICN). 


Combined with the existing IP function, the ICN function provides support for native ICN and/or 
the dual transport (ICN/IP) functionality. See Section 5.4.1 for elaborate descriptions of these 
functional layers. 


The TCL can use several mechanisms for transport selection. It can use a per-application 
configuration through a management interface, possibly a user-facing setting realized through a 
user interface, like those used to select cellular over Wi-Fi. In another option, it might use a 
software API, which an adapted IP application could use to specify the type of transport option 
(such as ICN) to take advantage of its benefits. 


Another potential application of TCL is in an implementation of network slicing with a local slice 
management capability or through an interface to an external slice manager via an API [GALIS]. 
This solution can enable network slicing for IP and ICN transport selection from the mobile 
terminal itself. The TCL could apply slice settings to direct certain applications traffic over one 
slice and others over another slice, determined by some form of a 'slicing policy’. The slicing 
policy can be obtained externally from the slice manager or configured locally on the mobile 
terminal. 


From the perspective of applications either on the mobile terminal or at a content provider, the 
following options are possible for potential use of ICN natively and/or with IP. 


IP over IP (IPoIP): In this scenario, the mobile terminal applications are tightly integrated with 
the existing IP transport infrastructure. The TCL has no additional function because packets 
are forwarded directly using an IP protocol stack, which sends packets over the IP transport. 


ICN over ICN (ICNoICN): Similar to case 1, ICN applications tightly integrate with the ICN 
transport infrastructure. The TCL has no additional responsibility because packets are 
forwarded directly using the native ICN protocol stack, which sends packets over the ICN 
transport. 


ICN over IP (ICNoIP): In this scenario, the underlying IP transport infrastructure is not 
impacted (that is, ICN is implemented as an IP overlay between mobile terminal and content 
provider). IP routing is used from the Radio Access Network (eNodeB) to the mobile backhaul, 
the IP core, and the Mobile Gateway (SGW/PGW). The mobile terminal attaches to the Mobile 
Gateway (SGW/PGW) using an IP address. Also, the data transport between Mobile Gateway 
(SGW/PGW) and content publisher uses IP. The content provider can serve content using 
either IP or ICN, based on the mobile terminal request. 
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One of the approaches to implement ICN in mobile backhaul networks is described in 
[MBICN]. It implements a General Tunneling Protocol - User Plane (GTP-U) extension header 
option to encapsulate ICN payload in a GTP tunnel. However, as this design runs ICN as an IP 
overlay, the mobile backhaul can be deployed using native IP. The proposal describes a 
mechanism where the GTP-U tunnel can be terminated by hairpinning the packet before it 
reaches the SGW if an ICN-enabled node is deployed in the mobile backhaul (that is, between 
eNodeB and SGW). This could be useful when an ICN data packet is stored in the ICN node 
(such as repositories and caches) in the tunnel path so that the ICN node can reply without 
going all the way through the mobile core. While a GTP-U extension header is used to carry 
mobile-terminal-specific ICN payload, they are not visible to the transport, including the SGW. 
On the other hand, the PGW can use the mobile terminal-specific ICN header extension and 
ICN payload to set up an uplink transport towards a content provider in the Internet. In 
addition, the design assumes a proxy function at the edge to perform ICN data retrieval on 
behalf of a non-ICN end device. 


IP over ICN (IPoICN): [IPoICN] provides an architectural framework for running IP as an 
overlay over the ICN protocol. Implementing IP services over ICN provides an opportunity to 
leverage the benefits of ICN in the transport infrastructure while there is no impact on end 
devices (MT and access network) as they continue to use IP. IPoICN, however, will require an 
interworking function (IWF) (and Border Gateway) to translate various transport primitives. 
The IWF function will provide a mechanism for protocol translation between IPoICN and the 
native IP. After reviewing [IPoICN], we understand and interpret that ICN is implemented in 
the transport natively; however, IP is implemented in MT, the eNodeB, and the Mobile 
Gateway (SGW/PGW), which is also called a network attach point (NAP). 


For this, said NAP receives an incoming IP or HTTP packet (the latter through TCP connection 
termination) and publishes the packet under a suitable ICN name (i.e., the hash over the 
destination IP address for an IP packet or the hash over the FQDN of the HTTP request for an 
HTTP packet) to the ICN network. In the HTTP case, the NAP maintains a pending request 
mapping table to map returning responses to the terminated TCP connection. 


Hybrid ICN (hICN): An alternative approach to implement ICN over IP is provided in Hybrid 
ICN [HICN]. It describes a novel approach to integrate ICN into IPv6 without creating overlays 
with a new packet format as an encapsulation. hICN addresses the content by encoding a 
location-independent name in an IPv6 address. It uses two name components, name prefix 
and name suffix, that identify the source of data and the data segment within the scope of the 
name prefix, respectively. 


At the application layer, hICN maps the name into an IPV6 prefix and, thus, uses IP as 
transport. As long as the name prefixes, which are routable IP prefixes, point towards a 
mobile GW (PGW or local breakout, such as CUPS), there are potentially no updates required 
to any of the mobile core gateways (for example, SGW/PGW). The IPv6 backhaul routes the 
packets within the mobile core. hICN can run in the mobile terminal, the eNodeB, the mobile 
backhaul, or the mobile core. Finally, as hICN itself uses IPv6, it cannot be considered as an 
alternative transport layer. 
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5.3. Integration of ICN in 4G Control Plane 


In this section, we analyze signaling messages that are required for different procedures, such as 
attach, handover, tracking area update, and so on. The goal of this analysis is to see if there are 
any benefits to replacing IP-based protocols with ICN for 4G signaling in the current architecture. 
It is important to understand the concept of point of attachment (POA). When a mobile terminal 
connects to a network, it has the following POAs: 


1. eNodeB managing location or physical POA 
2. Authentication and Authorization (MME, HSS) managing identity or authentication POA 
3. Mobile Gateways (SGW/PGW) managing logical or session management POA 


In the current architecture, IP transport is used for all messages associated with the control 
plane for mobility and session management. IP is embedded very deeply into these messages 
utilizing TLV syntax for carrying additional attributes such as a Layer 3 transport. The physical 
POA in the eNodeB handles both mobility and session management for any mobile terminal 
attached to a 4G network. The number of mobility management messages between different 
nodes in a 4G network per the signaling procedure is shown in Table 1. 


Normally, two types of mobile terminals attach to the 4G network: SIM based (which needs a 
3GPP mobility protocol for authentication) or non-SIM based (which connects to Wi-Fi networks). 
Both device types require authentication. For non-SIM based devices, Authentication, 
Authorization, and Accounting (AAA) is used for authentication. We do not propose to change 
mobile terminal authentication or mobility management messaging for user data transport using 
ICN. A separate study would be required to analyze the impact of ICN on mobility management 
messages, structures, and flows. We are merely analyzing the viability of implementing ICN as a 
transport for control plane messages. 


It is important to note that if MME and HSS do not support ICN transport, they still need to 
support a mobile terminal capable of dual transport or native ICN. When a mobile terminal 
initiates an attach request using the identity as ICN, MME must be able to parse that message and 
create a session. MME forwards mobile terminal authentication to HSS, so HSS must be able to 
authenticate an ICN-capable mobile terminal and authorize Create Session [TS23.401]. 


4G Signaling Procedures MME HSS SGW PGW PCRF 


Attach 10 2 3 2 íl 
Additional default bearer 4 0 3 2 1 
Dedicated bearer 2 0 2 2 0 
Idle-to-connect 3 0 al 0 0 
Connect-to-Idle 3 0 1 0 0 


Suthar, et al. Informational Page 15 


RFC 9269 Scenarios of ICN Integration in 4G August 2022 


4G Signaling Procedures MME HSS SGW PGW PCRF 


X2 handover 2 0 1 0 0 
S1 handover 8 0 3 0 0 
Tracking area update 2 2 0 0 0 
Total 34 2 14 6 3 


Table 1: Signaling Messages in 4G Gateways 


Anchorless mobility [ALM] provides a fully decentralized solution that is control plane agnostic 
to handle producer mobility in ICN. Mobility management at the Layer 3 makes its access 
agnostic and transparent to the end device or the application. The solution discusses handling 
mobility without having to depend on core network functions (e.g., MME); however, a location 
update to the core network may still be required to support legal compliance requirements such 
as lawful intercept and emergency services. These aspects are open for further study. 


One of the advantages of ICN is in the caching and reusing of the content, which does not apply 
to the transactional signaling exchange. After analyzing 4G signaling call flows [TS23.401] and 
message interdependencies (see Table 1), our recommendation is that it is not beneficial to use 
ICN for control plane and mobility management functions. Among the features of ICN design, 
Interest aggregation and content caching are not applicable to control plane signaling messages. 
Control plane messages are originated and consumed by the applications, and they cannot be 
shared. 


5.4. Integration of ICN in 4G User Plane 


We will consider Figure 1 when discussing different mechanisms to integrate ICN in mobile 
networks. In Section 5.2, we discussed generic experimental setups of ICN integration. In this 
section, we discuss the specific options of possible use of native ICN in the 4G user plane. The 
following options are considered: 


1. Using Dual transport (IP/ICN) mode in mobile terminal 
2. Using ICN in mobile terminal 

3. Using ICN in eNodeB 

4. Using ICN in Mobile Gateways (SGW/PGW) 


5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal 


The control and user-plane communications in 4G mobile networks are specified in 3GPP 
documents [TS23.203] and [TS23.401]. It is important to understand that a mobile terminal can be 
either consumer (receiving content) or publisher (pushing content for other clients). The protocol 
stack inside the mobile terminal (MT) is complex because it must support multiple radio 
connectivity access to eNodeB(s). 
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Figure 5 provides a high-level description of a protocol stack, where IP is used at two layers: (1) 
user-plane communication and (2) UDP encapsulation. User-plane communication takes place 
between the Packet Data Convergence Protocol (PDCP) and Application layer, whereas UDP 
encapsulation is at the GTP protocol stack. 


The protocol interactions and impact of supporting the tunneling of an ICN packet into IP or 
supporting ICN natively are described in Figures 5 and 6, respectively. 


+-------- + +-------- + 
| App | | CDN | 
+-------- + +-------- + 
|Transp. | | | | |Transp. | 
LENEE |i eaan o a an E ee E E E EAE AE oes | .|Converge| 
+-------- + | | | +-------- + | +-------- + 
E E E E rare hel eileen 
| PIGN IPS) | (LEN IRS | | LENZ ERI] 
| | | | all el | 
+-------- + | t----+----- + | t----- +----- + | +----- +--+ | +-------- + 
Eel | EE | [ele L | 
| PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | 
+-------- + | t---------- + | t----------- + | +----- + i il 
| RECA ale IRECS | RUDP eal | UDP | RUDE rae DP ERNE] | 
+-------- + | t---------- + | t----------- + | +----- + | 4 
J Wes We cI tute )| = lees Iles fc Mes ES ele et | 
+-------- + | t---------- + | t----------- + | t-------- + | t-------- + 
| L1 elle) TE Ipoh el) Ted [pe l It Weis le] tal | 
+-------- + | t----+----- + | t----- +----- + | +----- +--+ | +-------- + 
MT | BS (eNodeB) | SGW | PGW | 
Uu S1U $5/S8 SGi 


Figure 5: Dual Transport (IP/ICN) Mode in a Mobile Terminal 


The protocols and software stack used inside 4G-capable mobile terminals support both 3G and 
4G software interworking and handover. 3GPP Rel.13 specifications and onward describe the use 
of IP and non-IP protocols to establish logical/session connectivity. We can leverage the non-IP 
protocol-based mechanism to deploy an ICN protocol stack in the mobile terminal as well as in 
an eNodeB and Mobile Gateways (SGW/PGW). The following paragraphs describe per-layer 
considerations of supporting the tunneling of ICN packets into IP or supporting ICN natively. 


1. An existing application layer can be modified to provide options for a new ICN-based 
application and existing IP-based applications. The mobile terminal can continue to support 
existing IP-based applications or can develop new applications to support native ICN, ICNoIP, 
or IPoICN-based transport. The application layer can be provided with an option of selecting 
either ICN or IP transport, as well as radio interface, to send and receive data traffic. 


Our proposal is to provide an Application Programming Interface (APJ) to the application 
developers so they can choose either ICN or IP transport for exchanging the traffic with the 
network. As mentioned in Section 5.2, the TCL function handles the interaction of 
applications with multiple transport options. 
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2. The transport convergence layer helps determine the type of transport (such as ICN, hICN, or 
IP) and type of radio interface (LTE, Wi-Fi, or both) used to send and receive traffic. The 
application layer can make the decision to select a specific transport based on preference 
such as content location, content type, content publisher, congestion, cost, QoS, and so on. 
There can be an API to exchange parameters required for transport selection. Southbound 
interactions of the TCL will be either to IP or to ICN at the network layer. 


When selecting the IPoICN mode, the TCL is responsible for receiving an incoming IP or 
HTTP packet and publishing the packet to the ICN network under a suitable ICN name (that 
is, the hash over the destination IP address for an IP packet or the hash over the FQDN of the 
HTTP request for an HTTP packet). 


In the HTTP case, the TCL can maintain a pending request mapping table to map, returning 
responses to the originating HTTP request. The common API will provide a "connection" 
abstraction for this HTTP mode of operation, returning the response over said connection 
abstraction (akin to the TCP socket interface) while implementing a reliable transport 
connection semantic over the ICN from the mobile terminal to the receiving mobile terminal 
or the PGW. If the HTTP protocol stack remains unchanged, therefore utilizing the TCP 
protocol for transfer, the TCL operates in local TCP termination mode, retrieving the HTTP 
packet through said local termination. 


+---------------- + $----------------- + 
| ICN App (new) | |IP App (existing) | 
$--------- +------ + +------- +--------- + 
| | 
$--------- +---------------- +--------- + 
| Transport Convergence Layer (new) | 
+------ +---------------------+------- + 
| | 
+------ +------ + +------ +------- + 
|ICN function | | IP function | 
| (New | | (Existing) | 
+------ +------ + +------ +------- + 
| | 
+------ +--------------------- +------- + 
| PDCP (updated to support ICN) 
+----------------- +------------------ + 
| 
+----------------- +------------------ + 
RLC (Existing) 
+----------------- +------------------ + 
| 
+----------------- +------------------ + 
MAC Layer (Existing) 
+----------------- +------------------ + 
| 
+----------------- +------------------ + 
| Physical L1 (Existing) 
+------------------------------------ + 


Figure 6: Dual Stack ICN Protocol Interactions 
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3. The ICN function (forwarder) is proposed to run in parallel to the existing IP layer. The ICN 
forwarder forwards the ICN packets such as an Interest packet to an eNodeB or a response 
"data packet" from an eNodeB to the application. 


4. For the dual-transport scenario, when a mobile terminal is not supporting ICN as transport, 
the TCL can use the IP underlay to tunnel the ICN packets. The ICN function can use the IP 
interface to send Interest and Data packets for fetching or sending data, respectively. This 
interface can use the ICN overlay over IP. 


. To support ICN at the network layer in the mobile terminal, the PDCP layer should be aware 
of ICN capabilities and parameters. PDCP is located in the Radio Protocol Stack in the LTE Air 
interface, between the IP (Network layer) and Radio Link Control Layer (RLC). PDCP 
performs the following functions [TS36.323]: 

1. Data transport by listening to the upper layer, formatting, and pushing down to the RLC 


ui 


2. Header compression and decompression using ROHC 
3. Security protections such as ciphering, deciphering, and integrity protection 


4. Radio layer messages associated with sequencing, packet drop detection and 
retransmission, and so on. 


(ep) 


. No changes are required for the lower layer such as RLC, Media Access Control (MAC), and 
Physical (L1) as they are not IP aware. 


One key point to understand in this scenario is that ICN is deployed as an overlay on top of IP. 


5.4.2. Using ICN in Mobile Terminal 


We can implement ICN natively in the mobile terminal by modifying the PDCP layer in 3GPP 
protocols. Figure 7 provides a high-level protocol stack description where ICN can be used at the 
following different layers: 


1. User-plane communication 
2. Transport layer 


ICN transport would be a substitute for the GTP protocol. The removal of the GTP protocol stack 
is a significant change in the mobile architecture and requires a thorough study mainly because 
it is used not just for routing but for mobility management functions such as billing, mediation, 

and policy enforcement. 


The implementation of ICN natively in the mobile terminal leads to a changed communication 
model between the mobile terminal and eNodeB. Also, we can avoid tunneling the user-plane 
traffic from an eNodeB to the mobile packet core (SGW/PGW) through a GTP tunnel. 


For native ICN use, an application can be configured to use an ICN forwarder, and it does not 
need the TCL layer. Also, to support ICN at the network layer, the existing PDCP layer may need 
to be changed to be aware of ICN capabilities and parameters. 


The native implementation can provide new opportunities to develop new use cases leveraging 
ICN capabilities such as seamless mobility, mobile terminal to mobile terminal content delivery 
using a radio network without traversing the Mobile Gateways, and more. 
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Figure 7: Using Native ICN in Mobile Terminal 


5.4.3. Using ICN in eNodeB 


The eNodeB is a physical point of attachment for the mobile terminal where radio protocols are 
converted into IP transport protocols for dual transport/overlay and native ICN, respectively (see 
Figures 6 and 7). When a mobile terminal performs an attach procedure, it will be assigned an 
identity as either IP or dual transport (IP and ICN) or ICN endpoint. A mobile terminal can 
initiate data traffic using any of the following options: 


1. Native IP (IPv4 or IPv6) 
2. Native ICN 
3. Dual transport IP (IPv4/IPv6) and ICN 


The mobile terminal encapsulates a user data transport request into the PDCP layer and sends 
the information on the air interface to the eNodeB, which in turn receives the information and, 
using PDCP [TS36.323], de-encapsulates the air-interface messages and converts them to forward- 
to-core Mobile Gateways (SGW/PGW). As shown in Figure 8, to support ICN natively in an 
eNodeB, it is proposed to provide TCL capabilities in an eNodeB (similar to as provided in MT), 
which provides the following functions: 


1. It decides the forwarding strategy for a user data request coming from the mobile terminal. 
The strategy can decide based on preference indicated by the application, such as congestion, 
cost, QoS, and so on. 

2. It uses an eNodeB to provide an open API to external management systems in order to 
provide eNodeB the capability to program the forwarding strategies. 
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Figure 8: Integration of Native ICN in eNodeB 
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. The eNodeB can be upgraded to support three different types of transport: IP, ICN, and dual 


transport IP+ICN towards Mobile Gateways, as depicted in Figure 8. It is also proposed to 
deploy IP and/or ICN forwarding capabilities into an eNodeB for efficient transfer of data 
between the eNodeB and Mobile Gateways. The following are choices for forwarding a data 
request towards Mobile Gateways: 
1. Assuming the eNodeB is IP enabled and the MT requests an IP transfer, the eNodeB 
forwards data over IP. 


2. Assuming the eNodeB is ICN enabled and the MT requests an ICN transfer, the eNodeB 
forwards data over ICN. 
3. Assuming the eNodeB is IP enabled and the MT requests an ICN transfer, the eNodeB 
overlays ICN on IP and forwards user-plane traffic over IP. 


4. Assuming the eNodeB is ICN enabled and the MT requests an IP transfer, the eNodeB 
overlays IP on ICN and forwards user-plane traffic over ICN [IPoICN]. 


5.4.4. Using ICN in Packet Core Gateways (SGW/PGW) 


Mobile Gateways (a.k.a. Evolved Packet Core (EPC)) include SGW and PGW, which perform 
session management for MT from the initial attach to disconnection. When MT is powered on, it 


performs Network-Access-Stratum (NAS) signaling and attaches to PGW after successful 


authentication. PGW is an anchoring point for MT and is responsible for service creations, 
authorization, maintenance, and so on. The entire functionality is managed using an IP 


address(es) for MT. 


To implement ICN in EPC, the following functions are proposed: 


1. Insert ICN attributes in the session management layer for additional functionality with IP 
stack. The session management layer is used for performing attach procedures and assigning 
logical identity to users. After successful authentication by HSS, MME sends a Create Session 
Request (CSR) to SGW and SGW to PGW. 
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. When MME sends a Create Session Request message (Step 12 in [TS23.401]) to SGW or PGW, it 


includes a Protocol Configuration Option (PCO) Information Element (IE) containing MT 
capabilities. We can use PCO IE to carry ICN-related capabilities information from MT to 
PGW. This information is received from MT during the initial attach request in MME. Details 
of available TLV, which can be used for ICN, are given in subsequent sections. MT can 
support native IP, ICN+IP, or native ICN. IP is referred to as both IPv4 and IPv6 protocols. 


. For ICN+IP-capable MT, PGW assigns the MT both an IP address and ICN identity. MT selects 


either of the identities during the initial attach procedures and registers with the network 
for session management. For ICN-capable MT, it will provide only ICN attachment. For native 
IP-capable MT, there is no change. 


. To support ICN-capable attach procedures and use ICN for user-plane traffic, PGW needs to 


have full ICN protocol stack functionalities. Typical ICN capabilities include functions such as 
CS, PIT, FIB capabilities, and so on. If MT requests ICN in PCO IE, then PGW registers MT with 
ICN names. For ICN forwarding, PGW caches content locally using CS functionality. 


. PCO IE as described in [TS24.008] (see Figure 10.5.136 on page 656 and Table 10.5.154 on 


page 659) provides details for different fields. 
1. Octet 3 (configuration protocols define PDN types), which contains details about IPv4, IPv6, 
both IPv4 and IPv6, or ICN. 


2. Any combination of Octet 4 to Z can be used to provide additional information related to 
ICN capability. It is most important that PCO IE parameters are matched between MT and 
Mobile Gateways (SGW/PGW) so they can be interpreted properly and the MT can attach 
successfully. 


. The ICN functionalities in SGW and PGW should be matched with MT and the eNodeB 


because they will exchange ICN protocols and parameters. 


. Mobile Gateways (SGW/PGW) will also need ICN forwarding and caching capability. This is 


especially important if CUPS is implemented. User Plane Function (UPF), comprising the SGW 
and PGW user plane, will be located at the edge of the network and close to the end user. 
ICN-enabled gateway means that this UPF would serve as a forwarder and should be capable 
of caching, as is the case with any other ICN-enabled node. 


. The transport between PGW and CDN provider can be either IP or ICN. When MT is attached 


to PGW with ICN identity and communicates with an ICN-enabled CDN provider, it will use 
ICN primitives to fetch the data. On the other hand, for an MT attached with an ICN identity, 
if PGW must communicate with an IP-enabled CDN provider, it will have to use an ICN-IP 
interworking gateway to perform conversion between ICN and IP primitives for data 
retrieval. In the case of CUPS implementation with an offload close to the edge, this 
interworking gateway can be collocated with the UPF at the offload site to maximize the path 
optimization. Further study is required to understand how this ICN-to-IP (and vice versa) 
interworking gateway would function. 


5.5. An Experimental Test Setup 


This section proposes an experimental lab setup and discusses the open issues and questions that 
use of the ICN protocol is intended to address. To further test the modifications proposed in 
different scenarios, a simple lab can be set up, as shown in Figure 9. 
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4G Mobile Network Functions 
Figure 9: Native ICN Deployment Lab Setup 


The following test scenarios can be set up with deployment based on Virtual Machine (VM): 


1. SUB: An ICN-simulated client (using ndnSIM) - a client application on a workstation 
requesting content. 


N 


. EMU: Test unit emulating an eNodeB. This is a test node allowing for UE attachment and 
routing traffic subsequently from the Subscriber to the Publisher. 


3. EPC: Evolved Packet Core in a single instance (such as Open5GCore [Open5GCore]). 
4. CDN: Content delivery by a Publisher server. 


For the purpose of this testing, ICN-emulating code can be inserted in the test code in EMU to 
emulate an ICN-capable eNodeB. An example of the code to be used is NS3 in its LTE model. The 
effect of such traffic on EPC and CDN can be observed and documented. In a subsequent phase, 
EPC code supporting ICN can be tested when available. 


Another option is to simulate the UE/eNodeB and EPC functions using NS3's LTE [NS3LTE] and 
EPC [NS3EPC] models, respectively. The LTE model includes the LTE Radio Protocol stack, which 
resides entirely within the UE and the eNodeB nodes. This capability provides the simulation of 
UE and eNodeB deployment use cases. Similarly, the EPC model includes core network interfaces, 
protocols, and entities, which reside within the Mobile Gateways (SGW/PGW), and MME nodes 
and partially within the eNodeB nodes. 


Even with its current limitations (such as IPv4 only, lack of integration with ndnSIM, and no 
support for UE idle state), LTE simulation may be a very useful tool. In any case, both control and 
user-plane traffic should be tested independently according to the deployment model discussed 
in Section 5.4. 


6. Expected Outcomes from Experimentation 


The experimentation explained in Section 5 can be categorized in three broader scopes as 
follows. Note that further research and study is required to fully understand and document the 
impact. 


Architecture scope: to study the aspect of use of ICN at the user plane to reduce the 


complexities in current transport protocols while also evaluating its use in the control plane. 


Performance scope: to evaluate the gains through multicast, caching, and other ICN features. 
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Deployment scope: to check the viability of ICN inclusion in the 3GPP protocol stack and in real- 
world deployments. 


6.1. Feeding into ICN Research 


Specifically, we have identified the following open questions, from the architectural and 
performance perspective, that the proposed experiments with ICN implementation scenarios in 
4G mobile networks could address in further research: 


1. Efficiency gains in terms of the amount of traffic in multicast scenarios (i.e., quantify the 
possible gains along different use cases) and latency for cached content, mainly in the CDN 
use case. 


N 


. How the new transport would coexist or replace the legacy transport protocols (e.g., IPv4, 
IPv6, MPLS, RSVP, etc.) and related services (e.g., bandwidth management, QoS handling, 
etc.). 


Ww 


. To what extent the simplification in the IP-based transport protocols will be achieved. The 
multiple overlays (e.g., the MPLS, VPN, Virtual Private LAN Service (VPLS), Ethernet VPN, 
etc.) of services in the current IP-based transport adds to the complexity on top of basic IP 
transport. This makes the troubleshooting extremely challenging. 


4. How the new transport can become service aware such that it brings in more simplicity in 
the system. 


ui 


. Confirm how (in)adequate ICN implementation would be in the control plane (which this 
document discourages). Given that the 5G system, as specified in [TS23.501] (Appendix G.4), 
encourages the use of name-based routing in the (5G) control plane for realizing the 5G- 
specific service-based architecture for control plane services (so-called network function 
service), it would be worthwhile to investigate whether the 4G control plane would benefit 
similarly from such use or whether specific 4G architectural constraints would prevent ICN 
from providing any notable benefit. 


6.2. Use of Results Beyond Research 


With the experiments and their outcomes outlined in this document, we believe that this 
technology is ready for a wider use and adoption, providing additional insights. Specifically, we 
expect to study the following: 


1. Viability of ICN inclusion in the 3GPP protocol stack, i.e., investigating how realistic it would 
be to modify the stack, considering the scenarios explained in Section 5.4, and completing 
the user session without feature degradation. 


2. Viability of utilizing solutions in greenfield deployments, i.e., deploying the ICN-based 
extensions and solutions proposed in this document in greenfield 4G deployments in order to 
assess real-world benefits when doing so. 


7. IANA Considerations 


This document has no IANA actions. 


Suthar, et al. Informational Page 24 


RFC 9269 Scenarios of ICN Integration in 4G August 2022 


8. Security and Privacy Considerations 


This section will cover some security and privacy considerations in mobile and 4G networks 
because of the introduction of ICN. 


8.1. Security Considerations 


To ensure only authenticated mobile terminals are connected to the network, 4G mobile 
networks implement various security mechanisms. From the perspective of using ICN in the user 
plane, the following security aspects need to be taken care of: 


1. MT authentication and authorization 
2. Radio or air interface security 


3. Denial-of-service attacks on the Mobile Gateway; services are either by the MT or by external 
entities in the Internet 


4. Content poisoning in either transport or servers 
5. Content cache pollution attacks 

6. Secure naming, routing, and forwarding 

7. Application security 


Security over the LTE air interface is provided through cryptographic techniques. When MT is 
powered up, it performs a key exchange between the MT's Universal Mobile Telecommunications 
System Subscriber Identity Module (USIM) and HSS/Authentication Center using NAS messages, 
including ciphering and integrity protections between MT and MME. Details for secure MT 
authentication, key exchange, ciphering, and integrity protection messages are given in the 3GPP 
call flow [TS23.401]. With ICN, we are modifying the protocol stack for the user plane and not the 
control plane. The NAS signaling is exchanged between MT and Mobile Gateways, e.g., MME, 
using the control plane; therefore, there is no adverse impact of ICN on MT. 


4G uses IP transport in its mobile backhaul (between an eNodeB and the core network). In case of 
provider-owned backhaul, the Service Provider may require implementing a security 
mechanism in the backhaul network. The native IP transport continues to leverage security 
mechanisms such as Internet Key Exchange (IKE) and the IP Security (IPsec) protocol. More 
details of mobile backhaul security are provided in 3GPP network security specifications 
[TS33.310] and [TS33.320]. When a mobile backhaul is upgraded to support dual transport 
(IP+ICN) or native ICN, it is required to implement security techniques that are deployed in the 
mobile backhaul. When ICN forwarding is enabled on mobile transport routers, we need to 
deploy security practices based on [RFC7476] and [RFC7927]. 


4G Mobile Gateways (SGW/PGW) perform some key functions such as content-based online/ 
offline billing and accounting, deep packet inspection (DPI), and lawful interception (LI). When 
ICN is deployed in the user plane, we need to integrate ICN security for sessions between MT and 
the gateway. If we encrypt user-plane payload metadata, then it might be difficult to perform 
routing based on contents and it may not work because we need decryption keys at every 
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forwarder to route the content. The content itself can be encrypted between publisher and 
consumer to ensure privacy. Only the user with the right decryption key shall be able to access 
the content. We need further research for ICN impact on LI, online/offline charging, and 
accounting. 


8.2. Privacy Considerations 


In 4G networks, there are two main privacy issues [MUTHANA]: 


1. User Identity Privacy Issues. The main privacy issue within 4G is the exposure of the 
International Mobile Subscriber Identity (IMSI). The IMSI can be intercepted by adversaries. 
Such attacks are commonly referred to as "IMSI catching". 


2. Location Privacy Issues. IMSI catching is closely related to the issue of location privacy. 
Knowing the IMSI of a user allows the attacker to track the user's movements and create a 
profile about the user and thus breach the user's location privacy. 


In any network, caching implies a trade-off between network efficiency and privacy. The activity 
of users is exposed to the scrutiny of cache owners with whom they may not have any 
relationship. By monitoring the cache transactions, an attacker could obtain significant 
information related to the objects accessed, topology, and timing of the requests [RFC7945]. 
Privacy concerns are amplified by the introduction of new network functions such as 
information lookup and network storage, and different forms of communication [FOTIOU]. 
Privacy risks in ICN can be broadly divided in the following categories [TOURANI]: 


1. Timing attack 

2. Communication monitoring attack 
3. Censorship and anonymity attack 
4. Protocol attack 

5. Naming-signature privacy 


The introduction of TCL effectively enables ICN at the application and/or transport layer 
depending on the scenario described in Section 5. Enabling ICN in 4G networks is expected to 
increase efficiency by taking advantage of ICN's inherent characteristics. This approach would 
potentially leave some of the above-mentioned privacy concerns open as a consequence of using 
ICN transport and ICN inherent privacy vulnerabilities. 


eS 


. IPoIP (Section 5.2) would not be affected as TCL has no role in it, and ICN does not apply. 


. The ICNoICN scenario (Section 5.2) has increased risk of a privacy attack, and that risk is 
applicable to the ICN protocol in general rather than specifically to the 4G implementation. 
Since this scenario describes communication over ICN transport, every forwarder in the 
path could be a potential risk for a privacy attack. 

. The ICNoIP scenario (Section 5.2) uses IP for transport, so the only additional ICN-related 
potential privacy risk areas are the endpoints (consumer and publisher) where, at the 
application layer, content is being served. 


4. The IPoICN scenario (Section 5.2) could have potentially increased risk due to possible 
vulnerability of the forwarders in the path of ICN transport. 


N 


oO 
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Privacy issues already identified in 4G remain a concern if ICN is introduced in any of the 
scenarios described earlier and compounds to the new ICN-related privacy issues. Many research 
papers have been published that propose solutions to the privacy issues listed above. For LTE- 
specific privacy issues, some of the proposed solutions [MUTHANA] are IMSI encryption by an 
MT; mutual authentication; concealing the real IMSI within a random bit stream of certain size 
where only the subscriber and HSS could extract the respective IMSI; IMSI replacement with a 
changing pseudonym that only the HSS server can map to the UF's IMSI; and others. Similarly, 
some of the proposed ICN-specific privacy concerns mitigation methods, applicable where ICN 
transport is introduced as specified earlier in this section, include the following [FOTIOU]: 


e Delay for the first, or first k, interests on edge routers (timing attack) 


e Creating a secure tunnel or clients flagging the requests as non-cacheable for privacy 
(communication monitoring attack) 


e Encoding interest by mixing the content and cover file or using a hierarchical DNS-based 
brokering model (censorship and anonymity attack) 


e Use of rate-limiting requests for a specific namespace (protocol attack) 


e Cryptographic content hash-based naming or digital identity in an overlay network (naming- 
signature privacy) 


Further research in this area is needed. Detailed discussion of privacy is beyond the scope of this 
document. 


9. Summary 


In this document, we have discussed 4G networks and the experimental setups to study the 
advantages of the potential use of ICN for efficient delivery of contents to mobile terminals. We 
have discussed different options to try and test ICN and dependencies such as ICN functionalities 
and changes required in different 4G network elements. In order to further explore potential use 
of ICN, one can devise an experimental setup consisting of 4G network elements and deploy ICN 
data transport in the user plane. Different options can be overlay, dual transport (IP + ICN), hICN, 
or natively (by integrating ICN with CDN, eNodeB, SGW, PGW, and a transport network). Note 
that, for the scenarios discussed above, additional study is required for lawful interception, 
billing/mediation, network slicing, and provisioning APIs. 


Edge Computing [CHENG] provides capabilities to deploy functionalities such as CDN caching 
and mobile user plane functions (UPFs) [TS23.501]. Recent research for delivering real-time video 
content [MPVCICN] using ICN has also been proven to be efficient [NDNRTC] and can be used 
towards realizing the benefits of using ICN in an eNodeB, edge computing, Mobile Gateways 
(SGW/PGW), and CDN. The key aspect for ICN is in its seamless integration in 4G and 5G networks 
with tangible benefits so we can optimize content delivery using a simple and scalable 
architecture. The authors will continue to explore how ICN forwarding in edge computing could 
be used for efficient data delivery from the mobile edge. 


Based on our study of control plane signaling, it is not beneficial to deploy ICN with existing 
protocols unless further changes are introduced in the control protocol stack itself. 
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As a starting step towards use of ICN in the user plane, it is proposed to incorporate protocol 
changes in MT, an eNodeB, and SGW/PGW for data transport. ICN has inherent capabilities for 
mobility and content caching, which can improve the efficiency of data transport for unicast and 
multicast delivery. The authors welcome contributions and suggestions, including those related 
to further validations of the principles by implementing prototypes and/or proof of concepts in 
the lab and in the production environment. 
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